소프트웨어 개발의 큰 질문들에 대한 겸손한 생각
작성일 : 2025.01.03
사이트 원본) https://www.seangoedecke.com/confidence/
안녕하세요. 오늘은 소프트웨어 개발에서 우리가 자주 마주치는 '큰 질문들'에 대해 이야기해보려 합니다.
우리는 정말 답을 알고 있을까?
마이크로서비스가 모놀리스보다 좋을까요? 팀이 기술적 방향을 직접 결정해야 할까요, 아니면 외부 아키텍트의 지시를 따르는 게 나을까요? 장기적이고 복잡한 프로젝트를 동적 타입 언어로 작성하는 게 좋을까요? 인터넷에서 10초만 둘러봐도 이런 주제들에 대해 마치 답이 명확한 것처럼 논쟁하는 많은 엔지니어들을 볼 수 있습니 다.
하지만 기술 업계에서 일하는 시간이 길어질수록, 저는 이런 큰 질문들에 대해 점점 더 확신이 없어집니다. 처음에 끔찍한 아이디어라고 생각했던 것들이 잘 작동하는 것도 보았고, 그 반대의 경우도 보았기 때문입니다.
경험만으로는 부족한 이유
왜 우리는 이런 질문들에 대한 확실한 답을 알 수 없을까요? 제가 생각하는 핵심적인 이유는 다음과 같습니다:
-
소프트웨어 개발의 기본적인 환경이 너무나 빠르게 변화하기 때문에, 이런 질문들에 대해서는 최근 20년 정도의 경험만이 의미가 있습니다.
-
20년이라는 시간은 이런 큰 질문들에 답하기에 충분하지 않습니다. 폭넓은 경험과 깊이 있는 통찰력이 모두 필요한데, 20년 안에 이 둘을 모두 얻기는 어렵기 때문입니다.
제 경험상 한 회사에서 어떤 결정의 장기적인 결과를 보려면 최소 3-5년이 필요합니다. 이는 20년 동안 최대 4개 정도의 다른 관점만을 얻을 수 있다는 의미입니다. 예를 들어, 한 직장에서는 실패한 모놀리스-마이크로서비스 전환을, 다른 직장에서는 성공적인 전환을 볼 수 있겠죠. 하지만 4개의 데이터 포인트로는 충분하지 않습니다.
기술적 의견과 초기 경력의 트라우마
그렇다면 왜 우리는 이런 큰 질문들에 대해 종종 강한 확신을 가질까요? 저는 이런 의견들이 주로 초기 직장에서의 트라우마에 의해 형성된다고 생각합니다.
제 경우를 예로 들어보겠습니다:
-
Redux 스타일의 상태 관리에 대해 항상 의심스러운 시각을 가지고 있는데, 이는 모든 UI 상태를 글로벌 Redux 스토어에 강제로 넣어야 했던 첫 React 프로젝트의 경험 때문입니다.
-
로컬 개발 환경에서 Docker 서비스 클러스터를 구성하는 것을 싫어하는데, 이는 매주 10-30%의 시간을 환경 유지보수에 써야 했던 과거의 경험 때문입니다.
우리가 알 수 있는 것은?
물론 시니어 엔지니어라면 이런 큰 질문들에 대한 의견을 가져야 합니다. 우리는 실제로 타입이 있는 언어와 없는 언어 중 선택을 해야 하고, 모놀리스 코드베이스를 어떻게 다룰지 전략을 세워야 합니다.
하지만 중요한 것은 우리가 틀릴 수 있다는 것을 인정하고, 극단적인 입장 대신 균형 잡힌 시각을 가지려 노력하는 것입니다. 순수 객체지향 프로그래밍만을 고집하는 것과 같은 경직된 태도는 피해야 합니다.
결론
기술적인 선택에 있어 절대적인 정답은 없습니다. 우리의 의견은 종종 개인적인 경험과 트라우마에 기반 하며, 더 많은 경험을 쌓을수록 오히려 덜 확신을 가지게 됩니다. 이는 우리가 더 겸손하고 열린 마음을 가져야 한다는 것을 의미합니다.
요약
소프트웨어 개발에서 절대적인 정답은 없다는 핵심 메시지를 담고 있는 글입니다. 주요 포인트는 다음과 같습니다:
기술적 결정의 한계
- 소프트웨어 개발의 큰 질문들(마이크로서비스 vs 모놀리스 등)에 대해 확실한 답변은 존재하지 않음
- 개인의 경험만으로는 충분한 결론을 내리기 어려움
- 20년의 경력으로도 소프트웨어 개발의 장기적 결과를 완전히 이해하기 힘듦
경험의 한계
- 직장을 3-5년마다 옮기면 다양한 회사의 방식을 볼 수 있지만, 깊이 있는 이해는 어려움
- 기술적 의사결정의 장기적 결과를 보려면 최소 16년 이상의 경험 필요
기술적 의견 형성 배경
- 대부분의 기술적 확신은 초기 직장 경험에서 비롯된 트라우마에 기반함
- 연구나 이론적 접근만으로는 소프트웨어 개발의 복잡성을 완전히 이해할 수 없음
결론
소프트웨어 개발은 기술적 측면뿐 아니라 사람과 관련된 요소가 매우 중요하며, 절대적인 해결책은 존재하지 않는다.
키워드
소프트웨어 개발, 기술적 의사결정, 경험의 한계, 기술 트라우마, 절대적 해결책 부재